AltME groups: search

Cross-Post from Android group:


New release of Rebol3 with graphics on Android: http://development.saphirion.com/experimental/r3-droid.apk

Changes:
-enable CTO and OTC functions
-fix window offset
-fix image! / loaders pixelformat color order
-fixed close button action (RL_Init failed?)
-improved WAIT
-added clipping(slow atm but works)
-added RESIZE/ROTATE events
-improved JNI calls synchronization
-added native keyboard input
-updated built-in R3-GUI version



Note this release is very early alpha so expect unstable situations 
or even crashes. Feel free to report bugs or any other feedback.


This gets us again one step closer to be able to create Android apps 
with Rebol. Simple, small, fast. :-)

Then you will of course need to resize the panel and the window.

I don't know if it is usefull to have sliders in there, but what 
happens if menu is larger than app window, or app window is near 
screen-face border? Will menu wrap to the other side then? What happens 
if you resize main window etc?

also when first showing the window, the view area is only in about 
the upper left quarter of the window. a resize solves this.

Well i mean that when i start ALTME in i.e. 500x500 and then resize 
with mouse I dont see any screen stripes while resizing, but when 
I do this with a simple window under rebol I do see lots of screen-stripes 
during resize untill I loosen my finger from the mouse button...

has there been a silent upgrade to AltMe lately? since a week or 
two, when opening AltMe, its window will resize fullscreen and no 
way to resize it, it will keep resizing fullscreen.. OSX10.6.2 AltMe 
1.2.17

What is the etiquette for using metadata in a REBOL header?  Here's 
some scenarios:

A) From Viewtop:

	REBOL [
		type: 'index
	]

	title "My RebPage"


This is clearly ok, and a good way for an application to determine 
the disposition of data - in this case a Dialect.

B) I use this for QM modules:

	REBOL [
		type: 'module
		exports: [do-something]
	]

	var: 1
	do-something: func [val][val * var]


This adds a little more, as the 'exports block is more than just 
an 'id, it's contents are bound to the application.  Moreover, 'exports 
is not in the standard header.


C) A hypothetical dialect definition with some 'do code (I'll use 
VID to demonstrate):

	REBOL [
		title: "My Application Window"
		type: 'vid
		locals: [mybtn myarea]
		on-close: [save-all quit]
		options: [resize min-size (config/min)]
	]

	h1 "My Small App"
	myarea: area "Some Text"
	mybtn: btn "Submit" [save-all]



Now obviously all these cases can be fleshed out with R2, but is 
this abuse of the header?  There's still no security issue 'loading 
the file, indeed it takes a special handler to actually execute the 
code.  But again, is this taking the header where it shouldn't go? 
 What of R3?

I have a window that I want to make a dialog box .... so I do an 
inform on the layout.

Is it possible to make the resultant window resizable ... a la ... 
view/options layout [......] [resize]

Another thing ..... running on WinXP under view from 1.2.5 & upwards 
....
view/options layout [btn "Test"] [resize]

.... gives me a window that is only partly filled in with the default 
background color?

event system is stopped when you resize the window: try to do something 
at each clock tick (at 'rate speed,) and you'll see that no event 
is processed while resizing

sorry, even busy loop are stopped. no code execution while resizing: 
when you start resizing with mouse, all executed code stops, when 
you finish resizing, code resumes and an event 'resize in generated. 
So no refresh during window resize or movement (white background 
visible, truncated display, and others glitches), but only after.

it seems to me, that backeffect is recalculated wrongly, if 'resize 
window option is used. Can anyone confirm? It seems as low-level 
buffering bug - I can see background screen underneath :-)

That guys, but those are by-solutions. I regard it being bug - background 
is background, no matter if you resize or not :-) Rebol resizing 
is rather weak anyway - I have seen no other app, which freezes its 
UI when you resize its window ....

correct me if I'm wrong, but I seem to remember that VIEW can set 
a minimum size a window can have using /options 'RESIZE ?

I have done some work on it for the word-browser. Just look the code 
(desktop\rebol.com\tools\word-browser) :

- There is a patch to the resize function (maybe you can use it to 
refresh the list to the same size?) line 65

- There is a scroll-text-list func (line 414) that is called by the 
window/feel (line 381) for the mouse-wheel

haven't tested with that yet. I have a custom event function for 
closing the main window:

insert-event-func func [face event] [
  if event/type = 'resize [
    help-window-resize
    main-resize
  ]
  either event/type = 'close [
    either event/face/text = main-window-title [
      if request/confirm "Afslut programmet?" [quit event]
    ][
      event
    ]
  ][
    event
  ]
]

REBOL[]

scroll-pane: make face [
    color: red

    set-bounds: func [ offset [pair!] size [pair!] ] [ ; why not be called?
        print "$"
    ]
]


Window: make face [
    offset: 30x30
    pane: reduce [ scroll-pane ]
    feel: make feel [
        detect: func [face event ] [
            switch event/type [
                resize [
                    print "%"

                    Window/pane/1/set-bounds: 0x0 Window/size/x / 2
                    show Window
                ]
            ]
            event
        ]
    ]

]

view/options Window [ resize ]

; After resizing the window, only the "%" can be printed. Why set-bounds 
in the scroll-pane is not called?

view/new/options window: layout [box: box] 'resize

window/feel: make window/feel [detect: func [face event][if event/type 
= 'resize [box/color: red] event]]
do-events

view/new/options window: layout [box: box] 'resize
window/feel: make window/feel [

 detect: func [face event][if event/type = 'resize [print "detect 
 'resize" box/color: red] event]

 redraw: func [face action position][print "redraw" if face/size <> 
 face/old-size [print "changed size" box/color: blue]]
]
do-events

anton, but when you resize the window with mouse and by changing 
the size of the window face, I think the order might actually change.

I remember having a hell of time trying to resize the window properly 
without it causing a cascade of resize/show events...

or

my-data: read %./

window: center-face layout [text-list 640x480 font-name font-fixed 
data my-data]
view/options/title window 'resize "Files"

I'm working with resizing fields.  Setting the size of the field 
would be a good start. Figuring how to size the text-list on a window 
resize event would be a bonus.
I took a sample from the docs and modifed slightly.

REBOL []


displayData: ["A very long entry that will exceed the default width 
of the field that is displaying it."]
view/options/title layout [

 lines: text-list 640x480 bold font-size 14 font-name font-fixed data 
 to-block displayData [  		;; not sure how to auto-size the text-list 
 either 

 see-it/text: first lines/picked										;; how do I size this field
	show see-it												;; maybe its done here  
	]													;;
	see-it: info												;; or here?								
] [resize] "Test"

Thanks again in advance.

Basically you need to perform the resizing as an event function of 
the window using insert-event-func and set up sizes manually for 
each element that you wish to resize. However this is very tedious 
in the long run and very un-rebolish as there are absolutely no functions 
to handle resizing in standard VID/View.

So BrianH and I wrote a prototype for a resize engine, which we hoped 
would be part of REBOL/View 2.7.7. Brian is probably against spreading 
it as it's not debugged and complete, but I want to give it to you 
anyway, because I use it and it works fairly well, at least much 
better than the nightmare of manual resizing.

How do I get the window to resize withthe image face?

pic1: load %pic.jpg
pic_size: 200x200
view/new lay: layout [pic: image pic1 pic_size]
wait 2
unview lay 
pic/size: 50x50
view/new lay

you need to get a resize event from the window and apply that to 
the image. you can use INSERT-EVENT-FUNC for that.

somehow I can't seem to get the resize events in my window... that 
is strange.

rebol []


view*: system/view
; code taken with [probe second get in system/view 'wake-event]
view*/wake-event: func [port ] bind [
    event: pick port 1
    if none? event [

        if debug [print "Event port awoke, but no event was present."]
        return false
    ]
    either pop-face [

        if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
        pop-face event]
        do event
        found? all [
            pop-face <> pick pop-list length? pop-list
            (pop-face: pick pop-list length? pop-list true)
        ]
    ] [
        do event
        ; OUR HACK >>
        if event/type = 'resize [
        	event/face/feel/after-resize event/face event
        ]
        ; <<
        empty? screen-face/pane
    ]
] in view* 'self

window: view/new/options layout [bt: button "ok" ] [resize]

window/feel: make window/feel [
	after-resize: func [face event ][
		;probe event/type
		;probe "AFTER RESIZE"
		if event/type = 'resize [
			bt/offset/x: face/size/x / 2 - (bt/size/x / 2)
			show bt
		]
		event
	]
]
do-events

window: layout [i: image rate 5 load %gtfo.jpg key escape [halt]]

zoom-in: does [i/size: i/size * 5 / 4]
zoom-out: does [i/size: i/size * 4 / 5]
down: false
alt-down: false

insert-event-func [
	probe event/type
	switch/all event/type [
		down [down: true]
		up [down: false]
		time [if down [zoom-in]]		
		alt-down [alt-down: true]
		alt-up [alt-down: false]
		time [if down [zoom-in] if alt-down [zoom-out]]
	]
	center-face i
	show window
	event
]

view/options window [resize]

REBOL []


window: layout [i: image rate 5 load http://rebol.com/graphics/kits.jpg
key escape [halt]]

zoom-in: does [i/size: i/size * 5 / 4]
zoom-out: does [i/size: i/size * 4 / 5]
down: false
alt-down: false

insert-event-func [
	probe event/type
	switch/all event/type [
		down [down: true]
		up [down: false]
		time [if down [zoom-in]]		
		alt-down [alt-down: true]
		alt-up [alt-down: false]
		time [if down [zoom-in] if alt-down [zoom-out]]
	]
	center-face i
	show window
	event
]

view/options window [resize]

No, the dialect is simply a tool for building a face tree and it 
can be as complex as we want. Same in the R3 GUI.


How that face tree is otherwise managed during runtime (resizing, 
events, etc.) is up to other functions that exist elsewhere in VID, 
long after the role of the dialect is gone. What the VID Extension 
Kit does is add keywords for resizing and a few other elements, so 
the face tree holds a bit more information.


The resizing system is then used later to perform adjustments to 
the face tree, when you resize the window. That's just one example 
of doing only minor modifications to the dialect itself.

For listview it is like lv/resize 400x300. I used this syntax in 
the global event function as well as for the resize button.  It only 
worked when with the button when i didn/t resize the window before.

its possible the window cannot have time events, no matter its rate. 
 try using a master face in which you put everything, using its feel 
instead.


the window is managed differently than other faces by view... it 
has its own events like resize and stuff, so I wouldn't be surprised 
that its time handling is different.

you can add an event function to the window and trigger it on event/type 
= 'resize and then move the window according to its current size 
versus system/view/screen-size (or some such)

so I have to filter the correct event (resize) and object (the window/face) 
to calculate the new pos on the desktop.

windows are passed in the event/face, that is sure... so if resize 
events occur only for windows, you should be pretty safe in assuming 
that in this case the event/face is always a window.

there are MANY ways to do this, and depending on the surrounding 
code you have this may or may not be optimal, but this should give 
you an idea of what is going on.

rebol [
	title: "resizing example"
]


insert-event-func 	[
    switch event/type [
        resize      	[
			if in event/face 'on-resize [
				event/face/on-resize
			]
		]
		down 		[
			; always a window title, even if clicking on a button.
			probe event/face/text
		]  
    ]
    event
]


view/new/options layout [button "nope"] 'resize

win: layout [
	button "ok"
]

win: make win [
	on-resize: func [
		/local subface
	][
		; window size is already set at this point.
		subface: pane/1
		subface/offset: (size / 2) - (subface/size / 2)
		show self
	]
	offset/x: 200
]

view/new/options win 'resize


do-events

; I did a dif between the functions in VIEW and those in CORE for 
a default install.  What I get is this ( I hope it is useful to have 
al 106  in one place )

 alert  brightness?  caret-to-offset  center-face  choose  clear-face 
  clear-fields  confine  crypt-strength?

 dbug  deflag-face  desktop  dh-compute-key  dh-generate-key  dh-make-key 
  do-events  do-face  do-face-alt  do-thru  

 draw  dsa-generate-key  dsa-make-key  dsa-make-signature  dsa-verify-signature 
  dump-face  dump-pane  edge-size?  

 editor  emailer  exists-thru?  find-key-face  find-window  flag-face 
  flag-face?  flash  focus  get-face  

 get-net-info  get-style  hide  hide-popup  hilight-all  hilight-text 
  hsv-to-rgb  in-window?  inform  

 insert-event-func  inside?  install  launch-thru  layout  link-relative-path 
  load-image  load-stock  

 load-stock-block  load-thru  local-request-file  make-face  notify 
  offset-to-caret  open-events  outside?  

 overlap?  path-thru  read-net  read-thru  remove-event-func  request 
  request-color  request-date  request-dir  

 request-download  request-file  request-list  request-pass  request-text 
  reset-face  resize-face  rgb-to-hsv  

 rsa-encrypt  rsa-generate-key  rsa-make-key  screen-offset?  scroll-drag 
  scroll-face  scroll-para  set-face  

 set-font  set-para  set-style  set-user  show  show-popup  size-text 
  span?  stylize  textinfo  unfocus  

 uninstall  unlight-text  unview  vbug  view  viewed?  win-offset? 
  within?

I split into separate lines because I often want to put stuff in 
between, eg. a window resize handler.

Can i use a bigger font?

I can't reach the resize button to reduce the window somewhatt. How 
can this be done?

Is it possible to do a search in a group or the whole of ta world?

it handle the window resize too, Toc area is inserted into the same 
window and the entry clicking now scroll allways on the top the viewing 
area, MDP-Browser can produce HTML docs by just clicking one button 
the HTML  is stored localy and can be published back to the IOS server 
using the IOS REBOL/link client plublishing system. Editing of a 
document is possible existing on the IOS server or new we can store 
locally or publish it back (if the fileset yet exist on the IOS server).

view/options lay: layout [
	box "Bouncing window !!" 300x200 rate 1 feel [
		engage: func [f a e] [
			if a = 'time [lay/changes: 'restore show lay]
		]
	]
	text "Minimize me (if you can ;-)"
] 'resize

just a detail: in facets document, /span datatype is pair! . you 
could use it to store other data, but if you set a pair! to /span, 
/view will use it as virtual size for face (it still works in later 
betas, so one should be careful to not use it to store coordinates) 
ie:
f: layout [
   banner "Testing /span" guide 
   box 400x400 effect [gradient 1x1 0.0.0 255.255.255] 
   button "Hello!" return 
   text-list data ["just" "a" "list"] 
   image logo.gif logo.gif/size * 2
]

f/span: f/size  ; here we tells /view to use virtual coordinates 
for all subfaces

view/options f 'resize ; will give a fully resizable window (widgets 
included), but it only works for reducing window's size.

When you resize the tabbed view to a smaller size, I notice that 
the window obscures tabs to the right.  Can you put an arrow widget 
to scroll the tabs across ?

G4C TUT_MCListview

// ===========================================================
// A Multi Column (or Database) Listview..
// ===========================================================

WINDOW 126 90 367 373 "Listview"
	winattr style resize

xOnLoad
	// add some records to the listview & open..
	gosub #this AddRecords
	guiopen #this

xOnClose
	guiquit #this

// ===========================================================
// The listview
// - This is a normal MULTISELECT listview (the default).
// For this type to be triggered, you must double-click it.
// ===========================================================

XLISTVIEW 0 0 0 0 'The Title' "" var

	attr ID mylv
	attr resize 0022
	attr frame sunk

	// Give it a grid and allow the user to drag, drop & re-arrange
	// the lines - You can add more styles here..
	attr style grid/arrange/drag/drop/arrange

	// Add some columns. The first one we state with a '#'
	// in front to indicate we mean the 1st column.
	attr LVCOLUMN '#Item/width/120/TITLE/Description'

 attr LVCOLUMN 'Units/width/60/TITLE/Units/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Amount/width/60/TITLE/Amount/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Total/width/60/TITLE/Total/TYPE/number/JUSTIFY/RIGHT'

	// show the line double clicked..

 SetWinTitle #this 'SUM: $%Units x $%Amount = $($%Units * $%Amount)'


// ===========================================================
// This is a routine to add 100 records with various
// meaningless values to the above listview. Note how
// the fields can be used as normal variables.
// ===========================================================

xRoutine AddRecords
	local c

	use lv #this mylv

	// before we start, we HIDE the listview. This will
	// stop Gui4Cli from visually refreshing it every time
	// we add a record and will GREATLY increase the speed.
	// This will have no effect if the window is closed.
	// After we finish, we show it again..
	setevent #this mylv HIDE

	for c 0 100
		// add an empty record..
		lv add ''

		// Fill the fields with various values..
		%Item   = "This is Item $c"
		%Units  = $($c * 3)
		%Amount = $(($%Units / 2)*1000)
		%Total  = $($%Units * $%Amount)

	endfor

	// Show the listview again, refreshing the display..
	setevent #this mylv SHOW

// ===========================================================
// Right mouse button handling - Some menu choices..
// ===========================================================

xOnRMB


 QuickMenu -1 -1 'Select All/Remove selected/Add 100 records/#sepa/cancel'
	use lv #this mylv
	docase $$choice
		case = 0			// Select All
			lv select all
			break
		case = 1			// Remove selected
			lv delete selected
			break
		case = 2			// Add some records..
			gosub #this AddRecords
	endcase

Ashley, simple question.  Is the display/min-size expected to always 
open atleast the size of min-size.  I noticed it does not, however, 
when you attempt to resize the window, it will not allow resize smaller 
than min-size.  See example 2.1.2 in your RebGui Display guide.

Min-size limits the OS window size on resize only, the documentation 
will be updated to make this clearer (note that the OS window size 
includes an unknown number [to REBOL/View at least] of border / title 
pixels that varies by OS / Window style).

Hi, just few notes .... 


1) why new versions are not released as complete ones? The download 
is small already. I tried to point out my friend to it, and he missed 
0.3 version or so, which is required ...


2) box definitely does not resize properly. Still, so far, Romano's 
system was the most complete and the least errorless version I saw. 
Try to move resizing window here or there and you will get even cases 
as three lines of color boxes, no spacing, mixed together ...


3) lists - are we ready to overcome rebol limitation here? It works 
better, but still not flawlessly and not in system friendly manner: 
a) when moving "too fast" with mouse, it stays open b) in above and 
and other cases, ESC shoudl close it c) I understand we have use 
some "excuses" and workaraound for now, but that is not the way to 
go in future d) when moving away, it should stay open, last hilited 
item should stay hilited, close on esc, close on click-away, should 
be foxusable, ability to be driven by keyboard  - that is the only 
system friendly way


4) text-list multi mode - ctrl works, shift too, ctrl A too, but 
not in a system friendly way once again. Maybe I should check first, 
but IIRC, it should work following way - ctrl selects particular 
items. BUT - it should also deselect them - try ctrl A and then, 
holding Ctrl, press some item - it does not deselects them - that 
is imo wrong. Also - shift should mark all items between point of 
last press and active mouse position, deselecting all the rest, even 
if previsously selected ...

i would use a combination, window with min-size, but if min-size 
is smaller than min-layout-size, dont shrink layout further. keeps 
at least layout intact and user can resize back.

But this allows you to resize a window below an invisible threshold 
only to have your resize [partially] ignored when the layout jumps 
back to it's minimum size. I still maintain that setting a realistic 
min-size is not only subjective but the role of the GUI designer 
... if RebGUI tries to infer this setting it will invariably get 
it wrong ("why did it let my title field shrink to less than three 
characters ... everyone knows a one-char field is useless" type of 
issues).

min-size: This feature is only applied after the first try to resize 
the window. Than it's used, at startup time, the window has a "default" 
size. Whereever this size comes from.

tab-panel: will investigate
min-size: from the display users guide:

2.1.2 Min-Size

Specify a minimum OS window resize size.

display/min-size "Example" [
    tight
    text 80 blue "Some text" #W
    return
    box 80x40 #WH
] 400x400

Note


The min-size limit will only be enforced upon a window resize, and 
the size is inclusive of an OS specific number of border / title 
pixels. Also note that if any widgets are resizeable (#H and #W) 
and min-size has not been specified then RebGUI will assign a default 
value equal to the initial window size.


table: Already noted by Graham (arrow does not share label feel) 
- will add to list

Robert: "... a way to specify a starting size of the window that's 
not maximized. I want my app started with a size of 1024x768" Is 
that inclusive or exclusive of:


1) OS Window title bar and borders (which varies not only between 
OS, but also OS version and what DPI settings are in force)

2) Taskbar size and position (Windows) or Dock size and position 
(Mac) or ... (Linux)

Also, what happens if:

1) My display is 800x600, or the more common 1280x1024
2) I use a TabletPC or have an LCD in 768x1024 portrait mode?
3) Someone wants to use my app on a small PDA (300x200)


These are hard issues for a GUI designer to address in a generic 
manner. RebGUI provides some generalized approaches:


1) margin, gap, slider width, cell and font sizes - so you can choose 
sizes appropriates for the target display device
2) colors - so you can cater for 256-color (or lower) devices

3) Auto-resize directives (#HWXY) combined with /maximize - so your 
displays can use all available space without having to know the resolution 
in advance

4) /position refinements that are generic (top, bottom, first, second) 
- so you can design layouts in terms of, "I want this display on 
the left and this one on the right"


So the long answer to this question is, wanting to set an explicit 
display size is the wrong approach unless you are targeting a specific 
resolution device - and in that case just design your displays to 
use /maximise and be done with it. ;)

margin/spacing: added to the list.


The drop-down widget panel is actually a standard interface element 
on Mac (forget the name of it) which looks surprisingly similar to 
the JPG Pekr posted. A worthwhile addition I think, although hard 
to implement (as it changes the offset of every widget below it and 
forces a window resize).

Currently, every widget has to be prepared for window-, unit- and 
font-size changes at any time when redrawing. I'd expect them to 
be handled easier and even faster if they'd be slightly more explicit. 
But, as I've said, I may be missing the point here. Eventually you'd 
simply suggest to do 

	redraw: func [face action event] [
		if face/size <> face/old-size [face/feel/resize face]
		if face/old-sizes <> sizes [face/feel/rescale face]
		if any [
			face/font/old-font <> face/font
			face/font <> face/old-font
		][
			face/feel/rewrite font
		]
		:
	]

But it would be kind of boring to so in every single widget.

(Just thinking out loud)

resize

 is where you allow the size of elements to change, as you change 
 the size of the window etc. (e.g. if you change the size of the altme 
 window you get more space for the text, but the text size stays the 
 same)

/options

 opts [block!]	"Window options [no-title no-border resize] (must be: 
 block word)"

How is the svn related to get-rebgui?

 The SVN is for developers / experienced REBOLers ... it is used to 
 manage individual widget source files. %get-rebgui.r obtains a pre-built 
 distribution (including a merged %rebgui.r, %tour.r, images and demo 
 scripts). It is targeted at 'end users' who don't want to use SVN.

%tour.r is missing

 I want to add it *without* having to also add sample icon images 
 to the SVN. I'll probably just 'inline' the images so it's all in 
 one big file.


min-size: read this very carefully: http://www.dobeash.com/RebGUI/display.html#section-2.1.2


The Note says it all: "The min-size limit will only be enforced upon 
a window resize, and the size is inclusive of an OS specific number 
of border / title pixels. Also note that if any widgets are resizeable 
(#H and #W) and min-size has not been specified then RebGUI will 
assign a default value equal to the initial window size."

If I resize a window containing a chat widget, it corrupts the widget. 
 Can I link to the resize event to do a show on the chat widget?

And a related question.. Is it possible to resize the window when 
my picture is changed, so that the new picture doesn't get resized 
to the previous one's size?

 Is there any way to circumvent this for items that need a specific 
 pixel size, in my case a picture?

 image defaults to size -1x-1 which means *not* specifying a size 
 will default it to the image size.


 Is it possible to resize the window when my picture is changed, so 
 that the new picture doesn't get resized to the previous one's size?
 This should get you going:

	display "" [
		button [face/parent-face/size: 320x240 show face/parent-face]
	]


Note that in this case the size *is* in pixels as you are modifying 
a face object directly (as opposed to specifying a wudget's *unit* 
size). Hope that helps.

Having trouble with the #HWLVXY codes. I have two group-boxes next 
to each other. When I resize the window They overlap. I want them 
both to expand in size "H" and "W" but not overlap. Is this possible?

that is, if I wait until the window has resized and reset the span 
attribute after this .. then the tabs along the top did not resize, 
but the panel still does.

Pekr/Graham (re group-box resize overlap convo from 13-Jan) ... it's 
a limitation not a bug. The #H and #W directives assume they are 
by themselves in a given row/column.


Instead of ... unview/only face/parent-face/parent-face ... why not 
unview/ony find-window face
 ... performance over coding efficiency.  


Ashley hasn't been on line here since xmas eve ... is he on a rather 
extended holiday

 ... the GFC has forced me to allocate considerable resources elsewhere, 
 but I'm back for the time being.


button is blue. But with over effect, going to green (default?), 
and with press, going pink

 ... the over (theme light) and press (state light) colors are global. 
 118 fixes the problem whereby these states lost your original color 
 override.


We have arrow key navigation of tables.  How can we get the enter 
key to do the action?
 ... add 'table to behaviors/action-on-enter

sorry. I was not detailed enough,

the status line is not visible in the first place, although the lower 
border is inside the screen.

It's not possible to move the window with cursor keys, as it always 
snaps back.

It's not possble to resize the window by catching the upper edge 
with the mouse, as it always snaps down.
I hope I am clearer now.

Ashley - request-edit from RebDOC looks nice, it even scrolls, but 
it somehow misbehaves on my system. 

1) The Window could be smaller - does not even fit my 1280x800

2) When I try to resize it from the top, the window jumps around 
100pixels below

3) editing - only typing works ... e.g. hilighting by mouse does 
not work (strange, as it works for fields)
4) scroller misbehaves too ....

I like the way the pictures rearrange when you resize the window...

the main feature is the use of TWO hands... one drags, the other 
resize... that is really nice... grab a window with one hand... slide 
the ui with the other...

Weird. On every device I've tried the WinCE build with, the window 
didn't resize for the virtual keyboard, so the actual command line 
was covered up by the keyboard. Are you saying that this problem 
went away at some point with a more recent WinCE version?

I think that kind of general split window with settable (resize yes 
or no) panes, auto-scrollers, could be suitable?

It's a little buggy ATM and needs more features, but the resize algorithm 
resizes the UI, no matter what you resize: the window or an element 
in the UI. So if you have a box in the middle of the window with 
stuff around it, and you make it bigger, the other elements are automatically 
displaced.

Proper even spacing between UI elements. I think the window also 
sometimes does not resize properly, if content is resized. I may 
have missed some ways to do things in the layout dialect, so I may 
be wrong.

there are animations in the GUI and I can resize the entire window 
while they play.

So far, we are solving panel (page) style elements. What I miss is 
one layer above it, namel split-window. Hopefully it will not be 
problem. When I look e.g. at Outlook, the UI is - one window, background, 
and panels. When you move over the space between the panels, mouse 
pointer changes to that of resize. I wonder how would we do it?

BrianH: could you please elaborate a bit on following?


- what is make-panel function good for? To predefine statical layout, 
without viewing it?  General question then is, if we don't miss 'layout 
function with R3 VID. Is there more functions like that, e.g. make-face 
as with R2?


- could you please explain a bit 'plane style? I thought that 'panel 
style itself spans available window space, and if the content is 
larger, scrollers are used automatically (kind of area with auto-scrollers 
:-) And if we need to distinguis resize or don't resize states, wouldn't 
it be enough to use something like "panel all-pan options [resize?: 
no]"?

Thanks a lot ....

For that matter, is it possible to specify the size of the client 
area relative to the page size, have it resize with the page, and 
have the REBOL layout inside handle the resize as if a View window 
had been resized by the user?

Google uses Flash and they use javascript's onresize to call the 
flash script's window resize function.

this means that if no face in a layout can stretch or is elastic, 
the window will never allow resizing in that direction... trying 
to resize it beyon, will effetively resize the window back to its 
nominal size, allowing the other axis to resize freely.

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

yay!  real event model in place and functional for the OpenGL extension... 
its not a permanent solution but it will do for now.f


now the tedious job of creating stubs for a few hundred functions 
begins!


and hopefully by next week the first applications to show this off 
will be demoable  :-)


currently, including callbacks which create an object at each refresh, 
I can't  resize the window faster than the engine can redraw it (up 
to 1440x900, in 32 bit color, with a few shaded polygons ) , and 
this includes hundreds of lines of rebol being printed in the DOS 
shell.

Getting a window plus event handler up and running only using View 
(no load-gui) is pretty simple. The code, for those interested, is:

	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event][print event/type]]
	f: make system/standard/font [size: 36]

 d: make gob! [text: "Title" offset: 50x50 size: 300x200 flags: [resize]]
	append d make gob! [text: [font f "Text"]]
	append system/view/screen-gob d
	show system/view/screen-gob
	wait system/view/event-port

handler: func [event] [
			switch event/type [
				down [
				]
				up [
				]
				move [
				]
				resize [
					print [
						"resizing time:"
						dt [
							do-resize win event/offset
							;reflect the window gob boundaries
							win/parent/size: win/size
						]
					]
					print ["rendering time:" dt [show win/parent]]
				]
				close [
					quit
				]
			]
			none
		]

view [ title "hello world" button "test" print "hello" ]

does not show the button until you resize the window

It enforces a minimum size window but only after you first resize 
it

graham's code - apart from the initial window size, being collapsed, 
it also behaves strangerly resize size - the button keeps tight to 
bottom-left corner, when resizing ...

OK, when removing Title .... then my next question is - the window 
size is so small, that the button is not visible, unless I resize 
for the first time. But - Graham already reported that ....

what I did was create a GUI similar to this one:

view [
	panel 1 [check]
	panel 1 [button button button]
]


When you resize this vertically by a few pixels, the bottom panel 
will resize incorrectly. That is known and will be fixed. What I 
managed to do, was to either move or resize the window in a way, 
that would cause resizing to get stuck in a loop (!), so it goes 
up and down in size by a few pixels vertically on its own, and the 
window just sits there shaking up and down in size. If possible, 
we would like some help with reproducing that.

Henrik - to your above code example - what I don't like is, why the 
resize system dictates me, how to shring the window. When I want 
to maximize a window, it should not do so only in horizontal axis, 
but also in vertical one. That's just my opinion, but I would find 
it more predictable.

cause right now, the gui looks totally dead a part for the fact that 
it resizes (though its late by one window resize event.)

Got a pattern on the resize loop bug, but I guess it requires a very 
specific VM setup:

1. Start the R3 GUI and make a window. Maximize it.
2. Resize the VM desktop window

3. Hope that your resize action is slow enough to allow you to doubleclick 
the titlebar to de-maximize it.
4. Now it loops between maximized and normal size.

Perhaps there is some confusion about screen-face size changing.

I haven't had time to play a lot

- then don't, just pick one example, try to resize the window, and 
see how it works.

Could you try following code? You can eventually replace 'vpanel 
by 'hpanel [break-after: 1]. With vpanel, it just causes stack overflow, 
with hpanel, it kind of displays panel, but try to resize the window 
and see the mes ...


REBOL []

do %r3-gui.r3

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child

I really would like it if Carl could fix the event port so that it 
lets all resize events go to the even handlers.


right now, the graphics code has access to it, (because you can see 
the AGG gobs refresh when the window resizing) but the REBOL event 
handlers receive only the last resize event.  which means we cannot 
resize the view while its being dragged.

yep.  but in R3, I can actually see that the window resize events 
are being triggered while we drag the window size.. but for some 
reason they are not being pushed to the handler.

Yes, I see that point as well. Most of time I resize something it 
is to either gain more real estate (Obviously shrinking the window) 
or to see what is being hidden, as with a large spreadsheet or to 
show me more as one might do with an email client.  In the latter 
case, the objects resize larger but not the fonts, etc. This ALTME 
window is a good example. If I want to see more messages I can increase 
the size but I don't expect everything to just get bigger.

do-style window 'on-resize win-size